Techniques for generating microcontroller configuration information

ABSTRACT

A method and apparatus for configuring a programmable device, wherein a user may select from pre-defined user modules to select a configuration and corresponding function, representations of which are each displayed to the user, and instructions, based on the selected module, are automatically generated and used by the programmable device to implement the selected configuration and corresponding function.

REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/305,680 filed Nov. 28, 2011, which is a continuation of U.S. patentapplication Ser. No. 11/818,005 filed Jun. 12, 2007 now U.S. Pat. No.8,069,428, issued Nov. 29, 2011, which is a continuation of U.S. Ser.No. 10/002,726, filed Oct. 24, 2001, now U.S. Pat. No. 7,406,674, issuedJul. 29, 2008, all of which are incorporated by reference herein.

FIELD OF THE INVENTION

Embodiments of the present invention generally relate to the field ofmicrocontrollers. More specifically, embodiments of the presentinvention pertain to a method and apparatus for generating theconfiguration information for microcontrollers.

BACKGROUND

Microcontrollers function to replace mechanical and electromechanicalcomponents in a variety of applications and devices. Microcontrollershave evolved since they were first introduced approximately 30 yearsago, to the point where they can be used for increasingly complexapplications. Some microcontrollers in use today are also programmable,expanding the number of applications in which they can be used.

However, even though there are a large number of different types ofmicrocontrollers available on the market with a seemingly wide range ofapplicability, it is still often difficult for a designer to find amicrocontroller that is particularly suited for a particularapplication. Unique aspects of the intended application may make itdifficult to find an optimum microcontroller, perhaps necessitating acompromise between the convenience of using an existing microcontrollerdesign and less than optimum performance.

In those cases in which a suitable microcontroller is found, subsequentchanges to the application and new requirements placed on theapplication will likely affect the choice of microcontroller. Thedesigner thus again faces the challenge of finding a suitablemicrocontroller for the intended application.

One solution to the problems described above is to design (or havedesigned) a microcontroller customized for the intended application.However, this solution may still not be practical because of the timeneeded to develop a custom microcontroller and the cost of doing so. Inaddition, should the design of the intended application be changed, itmay also be necessary to change the design of the custommicrocontroller, further increasing costs and lead times. Moreover, theoption of designing a custom microcontroller is generally only availableto very large volume customers.

Application specific integrated circuits (ASICs) may suggest a solutionto the problem of finding a suitable microcontroller for an application.However, ASICs can also be problematic because they require asophisticated level of design expertise, and the obstacles of longdevelopment times, high costs, and large volume requirements stillremain. Solutions such as gate arrays and programmable logic devicesprovide flexibility, but they too are expensive and require asophisticated level of design expertise.

In an effort to overcome some of these disadvantages, somemicrocontroller suppliers (for example, Cypress MicroSystems in Bothell,Wash.) have started to offer standard parts that combine amicroprocessor with several user-configurable “building blocks.” Thesebuilding blocks may be configured to form many standard microprocessorperipherals, as well as to form unique peripherals as may be required bya specific application. Thus, a user of such products may be able totailor (or configure) such a standard product to meet his specificmicrocontroller requirements, in less time and at less cost than throughother means.

Unfortunately, the process by which such configurable blocks areconfigured is burdensome. The configurable blocks are designed to havewide application. As such, configuration generally involves setting alarge number of bits in a specific sequence in order to define aspecific function and interconnection with other blocks.

Many existing microcontrollers also have numerous configurationsettings. For example, it is not unusual for a given input/output portto be designed such that it is either input or output, and it mayfurther have a selectable pull up resistor.

In the prior art, the configuration process for both standardmicrocontrollers and configurable microcontrollers has been similar. Adesigner would study the device's information data sheets and manuallydetermine the value and order of a long string of bits that would createthe desired configuration. Subsequently, this string would be encodedinto microprocessor instructions for execution during the early stagesof operation, or initialization of the system.

In a very few instances, when a microcontroller has found very highacceptance in a particular application, high level tools have beencreated to support that particular microcontroller in that particularapplication. In such cases, a standard configuration is used and varioussoftware tools are built based on the standard configuration.

Unfortunately, in most design situations calling for a microcontroller,this is not the case. Configuration has been, for the most part, alabor-intensive manual process. Further, changes in the hardwareconfiguration tend to ripple through to the higher level software,requiring changes and recompilation of application software as well asin any software tools designed to ease the development process. Ineffect, if the microcontroller hardware changed, the software had tochange. Not just the application specific software, but also thesoftware tools (such as compilers) had to change.

SUMMARY

Therefore, it would be advantageous to provide a method and system forthe automatic generation of configuration information. A further needexists for a text readable description of the hardware resources of amicrocontroller. A still further need exists for the use of openstandards in describing configurable hardware.

Embodiments of the present invention provide a method and system for theautomatic generation of configuration information. Further embodimentsof the present invention provide for a text readable description of thehardware resources of a microcontroller. Still further embodiments ofthe present invention may use eXtensible Markup Language, an openstandard, to describe configurable hardware.

A method and apparatus for configuring a microcontroller is disclosed.An XML description of the microcontroller's hardware resources may beaccessed. A user may select from available hardware resources andpre-defined user modules to select a configuration. Configurationinformation, which may include register bit patterns and microprocessorinstructions, may be automatically generated. Additionally, applicationprogramming interface calls and structure, as well as interrupt vectortables may be automatically generated.

Another embodiment of the present invention may access predeterminedconfigurations of a microcontroller's hardware resources.

In one embodiment of the present invention, a microcontroller having anumber of configurable building blocks may be automatically configured.

In another embodiment of the present invention, user selectedconfiguration choices are combined with predetermined configurations toautomatically generate configuration information.

In yet another embodiment of the present invention, user configurationselections are checked against the hardware description for validity.

In still another embodiment of the present invention, a user may editconfigurable parameters within a computer implemented graphical userinterface.

Embodiments of the present invention provide improved ease of use andthe ability to manage greater complexity in the configuration ofconfigurable microcontrollers.

Therefore, these and other objects and advantages of the presentinvention will become obvious to those of ordinary skill in the artafter having read the following detailed description of the preferredembodiments that are illustrated in the various drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention are illustrated by way of exampleand not by way of limitation, in the figures of the accompanyingdrawings and in which like reference numerals refer to similar elementsand in which:

FIG. 1 is an illustration of a method of configuring a microcontroller,according to an embodiment of the present invention.

FIG. 2 is a block diagram of a computer system, which may be used as aplatform to implement embodiments of the present invention.

FIG. 3 illustrates an exemplary configurable microcontroller system,upon which embodiments of the present invention may be practiced.

FIG. 4 shows an exemplary User Module selection display, according to anembodiment of the present invention.

FIG. 5 shows an exemplary User Module placement display, according to anembodiment of the present invention.

FIG. 6 shows an exemplary screen detail of elements of FIG. 5, accordingto an embodiment of the present invention.

FIGS. 7A, 7B, 7C, 7D and 7E illustrate an exemplary User Moduledescription written in eXtensible Markup Language (XML), as may be usedby embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of the present invention, methodand apparatus for generating microcontroller configuration information,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. However, it will be recognizedby one skilled in the art that the present invention may be practicedwithout these specific details or with equivalents thereof. In otherinstances, well-known methods, procedures, components, and circuits havenot been described in detail as not to unnecessarily obscure aspects ofthe present invention.

Notation and Nomenclature

Some portions of the detailed descriptions which follow (e.g., process100) are presented in terms of procedures, steps, logic blocks,processing, and other symbolic representations of operations on databits that can be performed on computer memory. These descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. A procedure, computer executed step, logicblock, process, etc., is here, and generally, conceived to be aself-consistent sequence of steps or instructions leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated in a computersystem. It has proven convenient at times, principally for reasons ofcommon usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the followingdiscussions, it is appreciated that throughout the present invention,discussions utilizing terms such as “indexing” or “processing” or“computing” or “translating” or “calculating” or “determining” or“scrolling” or “displaying” or “recognizing” or “generating” or“accessing” or “selecting” or “tracking” or “displaying” or “informing”or “editing” or “adding” or the like, refer to the action and processesof a computer system, or similar electronic computing device, thatmanipulates and transforms data represented as physical (electronic)quantities within the computer system's registers and memories intoother data similarly represented as physical quantities within thecomputer system memories or registers or other such information storage,transmission or display devices.

Method and Apparatus for Generating Microcontroller ConfigurationInformation

This application makes reference to co-pending commonly-owned U.S.patent application Ser. No. 10/033,027, filed Oct. 22, 2001, attorneydocket number CYPR-CD00232 entitled “Microcontroller System on a Chip,”which is hereby incorporated herein by reference in its entirety.

The present invention is described in the context of development toolsfor designing with embedded microcontrollers. However, it is appreciatedthat the present invention may be utilized in other types ofcomputer-aided hardware and software design systems (for examplecompilers) where it may be necessary to describe various resources.

Traditional microcontrollers have a fixed set of digital and/or analogperipherals. Many of these peripherals may have configurable parameters.For example, a universal asynchronous receiver transmitter (UART) mayhave provision for several user-selectable configurations. These mayinclude a choice of baud rates, clock sources (internal or external),number of stop bits, parity (even, odd or none), etc. However, all suchconfiguration parameters apply to the same function, that of UART. Sucha fixed peripheral generally may not be reconfigured to perform acompletely different function, for example, a display controller.

A new class of microcontroller provides an analog and/or digitalsubsystem comprising many dynamically configurable blocks. An example ofsuch a device is the CY8C25x/26x family, commercially available fromCypress MicroSystems of Washington. These blocks do not, in general,provide the equivalent function of a traditional microprocessorperipheral. They may be thought of as fundamental building blocks.However, these blocks may be combined to create such functions. Infurther contrast to the fixed peripherals of a traditionalmicrocontroller, these blocks may be recombined in a differentcombination to perform a different function.

Importantly, these different combinations of blocks producing differentfunctions may exist at different times within the same system. Forexample, a set of blocks configured to perform the function of analog todigital conversion may sample a signal. After processing that signal inthe digital domain, those same blocks (perhaps in conjunction with a fewothers) may be recombined in a different configuration to perform thefunction of digital to analog conversion to produce an output signal.

The present invention provides a method and system for managing theconfiguration of and generating configuration information for bothtraditional microcontrollers with configurable peripherals and this newclass of microcontrollers with dynamically configurable blocks.

FIG. 1 illustrates a method 100 of configuring a microcontroller,according to an embodiment of the present invention.

In step 110, a description of the hardware resources may be accessed.This description may include a definition of the underlying hardware,i.e., what peripherals or configurable blocks are available, and theconfigurable parameters that must be set to operate. In a preferredembodiment of the present invention, the underlying hardware isdescribed in well understood names versus mnemonics, e.g.,“conversion_complete_interrupt” versus “INT6.” It is appreciated thatother well-known naming conventions are well suited to embodiments ofthe present invention.

In a preferred embodiment, this description is a data set, which may becontained in a plurality of files substantially compliant witheXtensible Markup Language, or XML.

XML is a well-known open standard, and is text based. As a text basedstructure, a wide variety of computer tools may be used to create andedit such a description. Being text based, it is also compatible withthe widest variety of network transmissions and can be easilytransferred between computers having different character setdescriptions, such as ASCII and EBCDIC. Descriptions having non-textcharacters may be more limited in their applications.

It is appreciated, however, that embodiments of the present inventionare well suited to other well-known data formats.

In an embodiment of the present invention, a separate software toolaccesses the descriptive data set. A significant benefit of separatingthe data set from the software tool is that the software tool does nothave to change (e.g., re-writing or recompiling) if the hardwarechanges. Only the data set needs to be modified to reflect such achange. Changes to a text based data file are significantly less complexthan changes to executable software.

Additional benefits derive from this arrangement as well. For example,supporting new hardware may only require the mere addition of new filesinto a module library (directory). Additionally, the hardwaredescription files may be used across a variety of computer platforms andoperating systems. Further, since the software tool isn't changing witheach new or modified piece of hardware, engineering resources may bededicated to increasing the quality of the software, rather thansupporting new functionality.

This description may also include lists of standard configurations thathave been predetermined, either by the users or the manufacturers, to beuseful. Such a configuration in a traditional microcontroller might be“RS-232 9600 baud,” which would be a set of bit patterns to configurethe (fixed function) UART to select the appropriate clock source, stopbits, parity, etc. for this standard form of communication.

Similarly, a standard configuration of configurable blocks might be ananalog to digital converter labeled “6_bit_ADC.” This standardconfiguration would combine analog and digital blocks to produce asix-bit analog to digital converter.

We label such standard configurations as user modules, and such usermodules may be defined in the description of hardware resources.

Still referring to FIG. 1, in step 120 a user, typically interactingwith a computer implemented design tool, may select from availableconfigurations, including user modules and other capabilities of themicrocontroller hardware, to produce a desired configuration.

In a preferred embodiment of the present invention, the design tool maytrack resources as they are assigned, providing feedback to the designersuch as available blocks and user modules. It is appreciated that suchfeedback is not required in embodiments of the present invention.

In step 130, the bit patterns corresponding to the selectedconfiguration may be automatically generated. In optional step 140,microprocessor instructions may be generated which, when executed causethe hardware to be configured according the selected configuration.

In optional step 150, application programming interface (API) callstructures may be automatically generated. Such APIs may correspond touser modules. For example, using the previous example of “6_BIT_ADC,” anAPI call might take the form of “GET_(—)6_(—) BIT_ADC_VALUE.” Usingmeaningful names in such an automatically generated structure is moreuseful to human designers who must maintain the software thanpseudo-random unique names generated by computer processes, such as“ZYX-1.” Microprocessor instructions required to perform this task andreturn the value to the calling software may be automatically generated.

In optional step 160, an interrupt vector table may be automaticallygenerated. Again using the example of “6_BIT_ADC,” instructions to setthe “conversion complete” interrupt to level 6 may be automaticallygenerated. Further, instructions to initialize the interrupt vectorcorresponding to level 6 may be automatically generated, and a shell forthe interrupt service routine may be automatically created. Finally,since this example also includes an API, the shell software may becompleted to, for example, read the result register from the “6_BIT_ADC”and place that value on the stack to be passed back to the callingprogram.

FIG. 2 illustrates circuitry of computer system 600, which may form aplatform for the implementation of embodiments of the present invention.Computer system 600 includes an address/data bus 650 for communicatinginformation, a central processor 605 functionally coupled with the busfor processing information and instructions, a volatile memory 615(e.g., random access memory RAM) coupled with the bus 650 for storinginformation and instructions for the central processor 605 and anon-volatile memory 610 (e.g., read only memory ROM) coupled with thebus 650 for storing static information and instructions for theprocessor 605. Computer system 600 also optionally includes achangeable, non-volatile memory 620 (e.g., flash) for storinginformation and instructions for the central processor 605, which can beupdated after the manufacture of system 600.

Computer system 600 also optionally includes a data storage device 635(e.g., a rotating magnetic disk) coupled with the bus 650 for storinginformation and instructions.

Also included in computer system 600 of FIG. 2 is an optionalalphanumeric input device 630. Device 630 can communicate informationand command selections to the central processor 600. Device 630 may takethe form of a touch sensitive digitizer panel or typewriter-stylekeyboard. Display device 625 utilized with the computer system 600 maybe a liquid crystal display (LCD) device, cathode ray tube (CRT), fieldemission device (FED, also called flat panel CRT), light emitting diode(LED), plasma display device, electro-luminescent display, electronicpaper or other display device suitable for creating graphic images andalphanumeric characters recognizable to the user. Optional signalinput/output communication device 640 is also coupled to bus 650.

System 600 optionally includes a radio frequency module 660, which mayimplement a variety of wireless protocols, for example IEEE 802.11 orBluetooth.

FIG. 3 illustrates an exemplary configurable microcontroller system 300,upon which embodiments of the present invention may be practiced. It isappreciated that the present invention is well suited to a wide range ofwell know and future configurable microcontroller systems.

Microcontroller system 300 may contain microcontroller 350.Microcontroller 350 may execute instructions stored within memoryelements of microprocessor system 300 to configure configurable elementsof microcontroller system 300, including analog SoCblocs 310, DigitalSoCblocs 320, programmable interconnect 330 and configurable I/Otransceivers 340. Configuration information for these configurableelements may have been generated by embodiments of the presentinvention.

Microcontroller system 300 may include analog SoCblocs 310. “SoC” is atrade name of Cypress MicroSystems of Washington for “System on (a)Chip,” and refers to an architecture of low-level building blocks forcreating a wide variety of on-chip functions associated with amicrocontroller. Analog SoCblocs 310 may be an array of such low levelbuilding blocks designed to implement analog functions. Similarly,digital SoCblocs 320 may be an array of low level building blocksdesigned to implement digital functions.

Programmable interconnect 330 may be an array of configurablemultiplexing elements designed to interconnect low level building blockstogether and with other system resources. Configurable I/O transceivers340 allow signals created or accessed by configurations of buildingblocks to communicate off-chip.

FIG. 4 shows an exemplary User Module selection display 400, accordingto an embodiment of the present invention. User Module selection display400 may contain User Module Catalog window 420. User Module Catalogwindow 420 may display all User Modules automatically loaded from theUser Module libraries. The User Modules may be organized by type. Thedisplayed names correspond to the type of the User Module.

User Module Selection Bar 410 may display the User Modules selected forthe current project. The instance name for the User Module may be shownbelow the icon in User Module Selection Bar 410. The instance name canbe changed at any time before code generation.

Block Diagram 430 and Data Sheet 450 correspond to the User Moduleshighlighted in the User Module catalog window 420. Block Diagram 430 mayprovide a block diagram of the highlighted user module, and may indicateconfigurable elements of the user module.

Data Sheet 450 may display a detailed datasheet for the selected usermodule, as would have been contained in a data book or accessed via theworld wide web in prior art systems. In this manner, a designer hasimmediate access to detailed engineering information regarding theselected user module, without having to refer to a printed book, or openan internet browser window which may obscure his work.

Embodiments of the present invention may be configured to allow onlyUser Modules that are seen in the User Module Selection bar 410 to beplaced during User Module placement.

Resource assignment window 440 may display the total resources availablein a particular device, and a summary of the resources used as they areplaced into the design. Resource assignment window 440 may display asummary of resources used/assigned in numerical and/or bar graphformats. Resource assignment window 440 may further change the color ofthe graph, for example, to yellow, to indicate that a specific resource,for example digital blocks, are almost used up. In addition, resourceassignment window 440 may display the graph in yet another color, forexample red, to indicate that all available resources of a particulartype have been used.

FIG. 5 shows an exemplary User Module placement display 500, accordingto an embodiment of the present invention. User Module placementinvolves the placement of selected User Modules onto the PSoC blocksavailable on the selected device.

User Module placement display 500 may include placement pane 510.Placement pane 510 may display a graphical representation of placedblocks and signal routings. The graphical placement and routing maycorrespond to the physical placement of such blocks on an integratedcircuit, or the graphical placement and routing may correspond tosimplified renderings of the microcontroller architecture.

Placed User Modules may have colored rectangles around their icons inthe User Module Selection Bar 410 and one or more blocks in thePlacement Pane 510 may be colored with the same color. The instance nameand block name will also be shown on the corresponding blocks.Embodiments of the present invention may be configured to allow onlyplaced User Modules to be parameterized and included in applicationgeneration.

User Module placement display 500 may also include global resourceswindow 530 that displays a list of the global resources available in thechosen device.

User Module placement display 500 may further include user moduleparameters window 520 that displays a list of configurable parametersfor the user module selected in user modules selection bar 410. In thisexample, there are no user configurable parameters for the selected usermodule “TX8_(—)1.”

FIG. 6 shows an exemplary screen detail 6000, which is a detail ofplacement pane 510. Detail 6000 shows the active areas for blockparameters, in particular block 6070, which may be displayed or editedby a user. In general, the active areas for the cursor indicator onblock 6070 associated with the parameter may be within the graphicalrepresentation of the block 6070 immediately surrounding the text blockand outside the block 6070 immediately adjacent to the text block whileextending to the end of the active area boundary line 6010.

When the mouse or other pointing device causes a cursor indicator (notshown) to move within the active area of a parameter, for exampleparameter text area 6060, the cursor may change to a horizontal DualIn-line Package (DIP) shape. If the cursor is left over the active areafor about one second, then a tool tip may appear showing the name of theparameter and its value.

The parameter value may be shown in the active area of the parameterimmediately above the line, for example parameter area 6060. If theparameter value has not yet been set, then the line may be rendered inan indicator color, for example, red, and a question mark may bedisplayed in place of the parameter value. The question mark may also bedisplayed in the same indicator color.

The CLOCK parameter 6040 may always map to an area in the upper leftcorner of the block 6070. Embodiments of the present invention may beconfigured so that there is only one parameter whose TYPE attribute isset to CLOCK in any one PSoC block within any User Module. The CLOCKparameter does not have a text block similar to parameter text area6060, but shows the triangle symbol within the block 6070.

The INPUT 6030 parameters (including parameter text area 6060) appear inthe lower left area of the block 6070. A maximum of 2 inputs can beshown on a block. The text may always be shown as “In 0” or “In 1” thatare assigned in alphabetical order of the INPUT parameters. If only oneINPUT parameter is defined for a particular block, then that input willappear at the bottom of the block and be shown as “In 0.”

The INPUT_MUX parameter 6050 is a special case parameter that may causethe line to be drawn between the top row of analog PSoC blocks, theANALOG_CT blocks, and the Pin Input MUX control above them. TheINPUT_MUX 6050 parameter does not have a bitfield associated with it, sothe BITFIELD attribute should be set to NONE. Consequently, an INPUT_MUX6050 parameter will not appear in the Parameter Pane. The value shownnext to the line is controlled by the Pin Input MUX control above. TheINPUT MUX 6050 parameter must only be used with ANALOG_CT blocks.

The OUTPUT 6020 parameters appear in the lower right area of the block.A maximum of 2 outputs can be shown on a block. The text may be alwaysshown as “Out 0” or “Out 1” that are assigned in alphabetical order ofthe OUTPUT parameters. If only one OUTPUT parameter is defined for aparticular block, then that parameter will appear at the bottom of theblock and be shown as “Out 0.”

The OUTPUT_(—)0 and OUTPUT_(—)1 parameters are similar to the OUTPUT6020 parameter except that the position of each parameter type is fixedin the block and the line outside the block is extended to connect toone of the two bus lines to the right of the blocks. The OUTPUT_(—)0parameter appears in the upper output position and the line extends tothe comparator bus line. The OUTPUT_(—)1 parameter appears in the loweroutput position and the line extends to the analog bus line.

The OUTPUT_(—)0_HIDDEN and OUTPUT_(—)1_HIDDEN parameters are similar tothe OUTPUT_(—)0 and OUTPUT_(—)1 parameters, except that the “_HIDDEN”implies that the parameter value itself is not made available to theGUI. For these parameters, the lines are drawn to the respective busline, but the text block within the block and the parameter value maynot be shown.

FIGS. 7A, 7B, 7C, 7D and 7E illustrate an exemplary User Moduledescription 700 written in eXtensible Markup Language (XML), as may beused by embodiments of the present invention.

The syntax of XML files follows other mark-up languages in that itconsists of tags, which represent elements. Elements can containattributes, and, in turn, attributes have values. All names in XMLfiles, whether they are tag names, attribute names, or attribute values,are case sensitive.

The user module description 700 may contain data including user moduleresource requirements, interconnection details, parameter description,and API code generation substitutions. Ultimately, the user moduledescription 700 may define registers, which are divided into bitfields.Bitfields may be set according to User Module placement andparameterization, thereby setting registers. The bitfields areassociated with resources, which are presented to the user, for examplein screen detail 6000. The resources are also how the GUI and the UserModule XML file access the bitfields.

The specific device description files reference the base devicedescription file and may define the pins that are available on the partand the RAM and ROM that is available on the part. The specific devicedescription files also cover all parts that share a common package typeinsomuch as the package falls into a similar category, for example28-pin dual-inline package, or 44-pin TQFP. Whether the part is DIP orTSOP does may not distinguish it as a distinct part description. Inother words, if a part shares a common pinout, including total pincount, with another part, then it may share a specific devicedescription file.

According to an embodiment of the present invention, the values of someof the attributes in user module description 700 are controlled by thenames used in the Device Description XML files, while others arecontrolled by the elements and attributes in the User Module XML fileitself. Each User Module XML file may contain the specifications forone, and only one User Module. From the root node <PSOC_DEVICE_DB> 702,the User Module XML file may contain one-and-only-one<PSOC_USER_MODULE_LIST> 704 element. The <PSOC_USER_MODULE_LIST> 704element can contain a multiplicity of <PSOC_USER_MODULE> elements, forexample <PSOC_USER_MODULE_LIST> 706, but generally will contain onlyone. The <PSOC_USER_MODULE> element may have the following attributes asdescribed below.

A NAME attribute may be the name of the User Module. A TYPE attributemay be the enumerated type of User Module. “HTML” attribute may be thename of file containing a User Module data sheet, for example data sheet450 in FIG. 4. The ICON attribute may be the name of file containing aUser Module icon graphic. METAFILE attribute may be the name of filecontaining User Module block diagram. API_PATH_TYPE attribute may be theXML file path relative to other files. RAM attribute may be the amountof RAM used by the User Module API. ROM attribute may be the amount ofROM used by the User Module API.

The NAME attribute is the reference for the User Module used by theDevice Editor. It is also the name that appears in under the icon in theUser Module Catalog on the User Module Selection view.

The TYPE attribute is an enumeration that places the User Module in acategory. The User Modules types serve to partition the User Modulesonto the different Outlook bars in the User Module catalog.

The HTML, ICON, and METAFILE attributes relate to the other files usedin the User Module Selection view. All of these attribute values are theliteral file names that must include the extension. The HTML attributespecifies the data sheet file that is displayed in the Data Sheet areaof the view. The METAFILE attribute specifies the extended metafile thatcontains the User Module block diagram. The block diagram appears in theBlock Diagram pane of the User Module Selection view. The ICON attributespecifies the file containing the User Module icon. The icon is used inthe User Module Catalog pane and the User Module Selection Bar.

The RAM and ROM attributes are the values used to determine the resourceusage for the User Module. The values of the RAM and ROM attributes aresubtracted from the total amount available on the device when the UserModule is selected. The resource usage gauge in the configuration tooltracks the RAM and ROM usage for the User Modules selected in thecurrent configuration.

The API_PATH_TYPE attribute specifies the relative path between the UserModule XML file and the other files. With the current library scheme,all User Modules should be set for CUSTOM. The other value, NORMAL isnot used or the attribute should not be included.

The <PSOC_USER_MODULE> element may contain one, and only one of each ofthe following elements <SHAPE>, <PARAMETER_LIST> and<API_REGISTER_ALIAS_LIST>.

The <SHAPE> element, for example <SHAPE> element 707, specifies the PSoCblocks and the resources required by the User Module, and establishessome reference names for use in other parts of the User Moduledescription. The <SHAPE> element has only a SHAPE_TYPE attribute. TheSHAPE_TYPE attribute may be set to BLOCK_LIST.

The <SHAPE> element consists of one or more <BLOCK_LIST> elements, forexample <BLOCK_LIST> element 710, and at most one <RESOURCE_LIST>element.

The <BLOCK_LIST> element describes a collection of PSoC blocks that areconnected between blocks within the <BLOCK_LIST> element. When multiple<BLOCK_LIST> elements are included within a <SHAPE> element, each<BLOCK_LIST> is placed on the device PSoC blocks independently.Connections between PSoC blocks from distinct <BLOCK_LIST> elements canexist through resources identified in the <RESOURCE_LIST> element.

The <BLOCK_LIST> has no attributes and consists of several <BLOCK>elements, for example <BLOCK> element 710. The <BLOCK> elements specifythe following information: Block name, the type of block required, Blockinterrupt generation, Block personalization and Block interconnection.

The <BLOCK> element may have the attributes described below. NAMEattribute may be the block reference name. The TYPE attribute may be theenumerated PSoC block type. The INTERRUPT_SOURCE attribute may be theblock interrupt handler name. The INTERRUPT_TYPE attribute may be theenumerated interrupt calling type.

The NAME attribute is a local name that identifies the block within theUser Module description. The NAME must be unique within a User Module,but similar names can be used in different User Modules. The NAMEattribute value appears in the GUI in the User Module Placement view.When a User Module is placed, the PSoC blocks onto which the User Moduleis placed show the instance name of the User Module with the local namedirectly under it.

The TYPE attribute specifies the type of PSoC block that the User Modulerequires. The valid values for the TYPE attributes include: DIGITAL,DIGITAL_COMM, ANALOG_CT, ANALOG_SCA, ANALOG_SCB and ANALOG_SC.

The difference between this list and the PSoC block types used in thedevice description is the addition of the ANALOG_SC type in the UserModule description. The ANALOG_SC block type indicates that thespecified block can be placed on an ANALOG_SCA or an ANALOG_SCB block.Similarly, a DIGITAL block type can be placed on a DIGITAL or aDIGITAL_COMM block.

The INTERRUPT_SOURCE and INTERRUPT_TYPE attributes relate to aninterrupt handler associated with the PSoC block. If an interrupthandler is not associated with the PSoC block, then the INTERRUPT_SOURCEand INTERRUPT_TYPE attributes should not be included in the <BLOCK>element. The INTERRUPT_SOURCE attribute value is a name that is used togenerate the interrupt handler name. The INTERRUPT_SOURCE attributevalue is appended to the User Module instance name to form the interrupthandler name. The INTERRUPT_TYPE attribute specifies whether a LJMP(long jump) or a CALL (to subroutine) is used when calling the interrupthandler from the vector table.

The <BLOCK> element may consist of one <REGISTER_LIST> element and atmost one <INPUT_LIST> element.

The <REGISTER_LIST> element, for example <REGISTER_LIST> element 712,may specify the PSoC block personalization. The bitfield values set inthis element are set on the PSoC block where the User Module is located.

The <REGISTER_LIST> consists of one-or-more <REGISTER> elements, forexample <REGISTER> element 714. The <REGISTER> element may have a NAMEattribute and one <BITFIELD_LIST> element. The NAME attribute value mustmatch one of the names of the registers in a PSoC block of similar typecontained in the <COMMON_BLOCK_LIST> element of the device description.

The <BITFIELD_LIST>, for example <BITFIELD_LIST> 716, consists ofone-or-more <BITFIELD> elements. The <BITFIELD> elements, for example<BITFIELD> element 718, may have NAME and VALUE attributes. The bitfieldNAME attribute must be one of those included in the <BITFIELD_LIST> of ablock of similar type contained in the <COMMON_BLOCK_LIST> of the devicedescription. Similarly, the VALUE attribute must be a value that isvalid for the specified bitfield as defined in the device description.

The <INPUT_LIST> element, for example <INPUT_LIST> 720 of FIG. 7B,specifies the interconnection between blocks and resources within theUser Module description. The <INPUT_LIST> element has no attributes andconsists of one-or-more <INPUT> elements. The <INPUT> element specifiesa connection between the block and another block or resource within theUser Module description. The relevance of an <INPUT> element is that aconnection with another PSoC block or resource on the device impliesthat a bitfield within the block registers must be set to a particularvalue.

The <INPUT> element may have the attributes described below. The SOURCEattribute may be the name of the resource or PSoC block that is thesource of the input. The TYPE attribute may be an enumeration of thetype of the SOURCE, either BLOCK or RESERVED_RESOURCE. The BLOCK_TYPEattribute may be an enumeration of the type of the block on which theblock is placed, either ANALOG_SCA or ANALOG_SCB. The REGISTER_NAMEattribute may be the name of the register within the block<REGISTER_LIST> containing the relevant bitfield. The BITFIELD attributemay be the name of the bitfield associated with the input.

The SOURCE attribute must match the name of another block or resourcewithin the User Module.

The TYPE attribute must match the SOURCE, whether the SOURCE is a BLOCKor RESERVED_RESOURCE.

The BLOCK_TYPE attribute is only relevant when the TYPE of the <BLOCK>element is ANALOG_SC. In this case, the bitfield for a connection mayvary depending on whether the <BLOCK> element was placed on anANALOG_SCA or an ANALOG_SCB block. If the bitfield is different, thendistinct <INPUT> elements specifying both cases must be included in the<INPUT_LIST> element for that <BLOCK> element.

The REGISTER_NAME attribute specifies the NAME attribute of the<REGISTER> element in the <REGISTER_LIST> element of the <BLOCK> thatcontains the relevant bitfield. If the bitfield name is unique, then theREGISTER_NAME can be omitted, but it is better practice to alwaysinclude it.

The BITFIELD attribute value specifies the NAME attribute of the<BITFIELD> element that is associated with the input.

The <RESOURCE_LIST> element, for example <RESOURCE_LIST> element 725 ofFIG. 7D, specifies the resources that the User Module requires. The UserModule uses resources to enable parameterization, enable connectionbetween blocks, or restrict placement options. There may be only one<RESOURCE_LIST> element in a <SHAPE> element. The one <RESOURCE_LIST>element contains all resources used by the User Module.

A<RESOURCE_LIST> consists of one-or-more <RESOURCE> elements. The<RESOURCE> element specifies the type of resource and connections fromother blocks or resources in the User Module description. The <RESOURCE>element may have attributes as described below.

The NAME attribute may be the reference name for the resource. The TYPEattribute may be the resource type.

The NAME attribute defines the reference name for the resource withinthe User Module. The TYPE attribute specifies the type of resourcerequired. Valid values for TYPE may include: COLUMN_INPUT,ANALOG_COLUMN_CLOCK_MUX, ANALOG_CLOCK_SELECT, ANALOG_DRIVER, GLOBAL_BUS,ANALOG_COMPARATOR_OUTPUT, ANALOG_COLUMN_OUTPUT,ANALOG_COMPARATOR_CONTROL, DECIMATOR, ANALOG_MODULATOR, PIN,TEMPERATURE_VOLTAGE and DIRECT_INPUT.

These values correspond to resources in the <RESERVED_RESOURCE_LIST> inthe device description.

The <RESOURCE> element contains an <INPUT_LIST> element, for example<INPUT_LIST> element 730 of FIG. 7D. The <INPUT> elements within the<INPUT_LIST> are similar to the <INPUT_LIST> element in the <BLOCK>element. The <INPUT> element for resources may have the followingattributes.

The SOURCE attribute may be the name of the resource or PSoC block thatis the source of the input. The TYPE attribute may be an enumeration ofthe type of the SOURCE, either BLOCK or RESERVED_RESOURCE. TheREGISTER_NAME attribute may be the name of the register within the block<REGISTER_LIST> containing the relevant bitfield. The BITFIELD attributemay be the name of the bitfield associated with the input.

In many cases, the resource does not have a register associated with it.In these cases, the BITFIELD attribute is set to NONE and theREGISTER_NAME attribute can be omitted.

The <PARAMETER_LIST> element, for example <PARAMETER_LIST> element 740of FIG. 7D, exposes bitfields to the GUI to allow the user to set theirvalues. The <PARAMETER> element associates the parameter with a bitfielddefines in the User Module shape. The values shown for the parametersare controlled by the bitfield values or a <PARAMETER_VALUE_LIST>element. The value list can also be limited with an <ALLOWED_VALUE_LIST>element. If a parameter has an ambiguous SOURCE, in terms of block type,then it is possible that the bitfield associated with the parameter hasa different name depending on block placement. For example, if theSOURCE block is TYPE ANALOG_SC, then some of the registers havedifferent names for the same bitfield in an ANALOG_SCA block as opposedto an ANALOG_SCB block. In this case, a parameter should be specifiedfor both block types based on the unique register names. When the blockis placed, the parameter that does not apply will disappear.

The <PARAMETER_LIST> element may contain at least one <PARAMETER>elements. The <PARAMETER> element may have the following attributes. TheNAME attribute may be the name of parameter. The TYPE attribute may bethe enumeration of parameter type. The SOURCE attribute may be the nameof PSoC block or resource containing the bitfield associated with theparameter. The REGISTER_NAME attribute may be the name of the registercontaining the bitfield associated with the parameter. The BITFIELDattribute may be the name of the bitfield associated with the parameter.The ORDER attribute may be the order that the parameters appear in thelist. The VALUE attribute may be the default value. The VALUE_TYPEattribute may be ENUM or INT. The default value is ENUM if attribute ismissing. The MIN attribute may apply only to VALUE_TYPE=INT, which isthe minimum inclusive parameter value. The MAX attribute may apply onlyto VALUE_TYPE=INT, which may be the maximum inclusive parameter value.

The NAME attribute may be the reference name for the parameter withinthe User Module. In the User Module Placement view, the NAME attributeis the name that appears in the Parameter Pane grid control. The ORDERattribute determines the order that the parameters appear, where theORDER “0” parameter is at the top with the remaining parameter listeddown in ascending order. If the ORDER attribute is not specified, thenthe parameters are listed in alphabetical order.

The SOURCE, REGISTER_NAME, and BITFIELD attributes specify the PSoCblock, or resource, and the bitfield, in the shape that contains thebitfield associate with the parameter. The SOURCE must be set to a NAMEincluded in the <SHAPE> element of a <BLOCK> element, or of a <RESOURCE>element. The REGISTER_NAME and BITFIELD attributes must also be includedin the <BLOCK> or <RESOURCE> element. A special keyword for the SOURCEattribute is ALL_DIGITAL. If the SOURCE for a parameter is set toALL_DIGITAL, then the parameter applies to a similar bitfield for alldigital PSoC blocks defined in the User Module. This value can be usedto set all clocks for the digital blocks to the same value.

The VALUE attribute specifies the default value for the parameter. Inthe case of a parameter that does not include a <PARAMETER_VALUE_LIST>element, the VALUE attribute must be included in the <BITVALUE_LIST> ofthe bitfield associated with the parameter. If a <PARAMETER_VALUE_LIST>is included, then the VALUE attribute value must be included in the<PARAMETER_VALUE_LIST> element.

The TYPE attribute may be a UI helper that controls the appearance ofparameters on the PSoC blocks in the Placement Pane. When a User Moduleis placed on to the PSoC blocks, some of the parameters may be shown onthe blocks. When parameters are shown on the PSoC blocks, then they maybe set from the Placement Pane by clicking on the active area for theparameter on the block, as shown in the Parameter Block Selectionscreen. The enumerated values of the TYPE attribute determine where onthe block the active area for the parameter is shown. The valid valuesfor the TYPE attribute are described below.

The CLOCK attribute may be the clock selection parameter. The INPUTattribute may be the input parameter. The INPUT_MUX attribute may be thespecial MUX input parameter. The INPUT_HIDDEN attribute may be thehidden parameter for input. The BLOCK attribute may be the general blockparameters. The BLOCK_HIDDEN attribute may be hidden parameter for ablock. The OUTPUT attribute may be the general output parameter. TheOUTPUT_(—)0 attribute may be the output parameter to comparator bus. TheOUTPUT_(—)1 attribute may be the output parameter to analog bus. TheOUTPUT_(—)0_HIDDEN attribute may be the hidden parameter to comparatorbus. The OUTPUT_(—)1_HIDDEN attribute may be the hidden parameter toanalog bus. The API attribute may be the parameter not associated withany bitfields.

The preferred embodiment of the present invention, a method andapparatus for generating microcontroller configuration information, isthus described. While the present invention has been described inparticular embodiments, it should be appreciated that the presentinvention should not be construed as limited by such embodiments, butrather construed according to the below claims.

1-20. (canceled)
 21. A computer-implemented method comprising:displaying a representation of a first user module corresponding to afirst configuration of a programmable device comprising a plurality ofconfigurable circuit blocks; displaying a representation of a seconduser module corresponding to a second configuration of the programmabledevice; receiving an input from a user to select the first user moduleor the second user module; and generating instructions that whenexecuted by the programmable device configure the programmable device toimplement a function corresponding to the selected module.
 22. Themethod of claim 21 wherein the first user module comprises informationdefining a first standard configuration of at least one of theconfigurable circuit blocks and the second user module comprisesinformation defining a second standard configuration of at least one ofthe configurable circuit blocks.
 23. The method of claim 21 wherein atleast one of the configurable circuit blocks comprises an analog circuitblock.
 24. The method of claim 21 wherein at least one of theconfigurable circuit blocks comprises a digital circuit block.
 25. Themethod of claim 21 wherein the configurable circuit blocks compriseanalog and digital circuit blocks.
 26. The method of claim 21 whereinthe programmable device comprises a microcontroller.
 27. The method ofclaim 21 further comprising: displaying an indication of a configurableparameter; receiving a user input selecting a configurable parameter tobe parameterized; and receiving a user input to parameterize the firstconfiguration of the first user module in accordance with the userinput.
 28. The method of claim 27 wherein the configurable parametercomprises a clock parameter.
 29. The method of claim 27 wherein theindication of the configurable parameter is displayed in a first formwhen the configurable parameter has not yet been parameterized anddisplayed in a second form after the configurable parameter has beenparameterized.
 30. The method of claim 21 further comprising receiving auser input changing an instance name of the first user module.
 31. Anon-transitory computer-readable storage medium comprisingcomputer-executed instructions that, when executed by a processorperform operations comprising: displaying a representation of a firstuser module corresponding to a first configuration of a programmabledevice comprising a configurable circuit block; displaying arepresentation of a second user module corresponding to a secondconfiguration of the configurable circuit block of the programmabledevice; receiving an input from a user to select either the first usermodule or the second user module; and generating instructions that whenexecuted by the programmable device configure the programmable device toimplement a function corresponding to the selected module.
 32. Thecomputer-readable storage medium of claim 31 wherein the first usermodule comprises information defining a first standard configuration ofthe programmable device and the second user module comprises informationdefining a second standard configuration of the programmable device. 33.The computer-readable storage medium of claim 31 wherein theconfigurable circuit block comprises an analog circuit block.
 34. Thecomputer-readable storage medium of claim 31 wherein the configurablecircuit block comprises a digital circuit block.
 35. Thecomputer-readable storage medium of claim 31 wherein the configurablecircuit block comprises both analog and digital circuit elements. 36.The computer-readable storage medium of claim 31 wherein theprogrammable device comprises a microcontroller.
 37. Thecomputer-readable storage medium of claim 31 further comprising:displaying an indication of a configurable parameter; receiving a userinput selecting a configurable parameter to be parameterized; andreceiving a user input to parameterize the first configuration of thefirst user module in accordance with the user input.
 38. Thecomputer-readable storage medium of claim 37 wherein the configurableparameter comprises a clock parameter.
 39. The computer-readable storagemedium of claim 37 wherein the indication of the configurable parameteris displayed in a first form when the configurable parameter has not yetbeen parameterized and displayed in a second form after the configurableparameter has been parameterized.
 40. The computer-readable storagemedium of claim 31 further comprising receiving a user input changing aninstance name of the first user module.